-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update EVP cipher APIs to gracefully handle null EVP_CIPHER_CTX #1398
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1398 +/- ##
=======================================
Coverage 77.18% 77.19%
=======================================
Files 426 426
Lines 71449 71465 +16
=======================================
+ Hits 55146 55165 +19
+ Misses 16303 16300 -3 ☔ View full report in Codecov by Sentry. |
@@ -255,6 +256,7 @@ static int block_remainder(const EVP_CIPHER_CTX *ctx, int len) { | |||
|
|||
int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, uint8_t *out, int *out_len, | |||
const uint8_t *in, int in_len) { | |||
GUARD_PTR(ctx); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why there are no guards for CipherInit_ex, CipherUpdate and CipherFinal_ex? ctx
is accessed there right away.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still see CipherInit_ex not having a GUARD_PTR, is there a reason for that?
aws-lc/crypto/fipsmodule/cipher/cipher.c
Line 142 in 4c0a39b
int EVP_CipherInit_ex(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *cipher, |
…new safety macro GUARD_PTR
Issues:
Resolves V1187459157
Description of changes:
This change does 3 things:
Call-outs:
This is an alternative approach to #1420.
The
__AWS_LC_ENSURE
macro uses thedo {} while (0)
trick to ensure the action is run once, anything passed into the macro doesn't accidentally expand and change the scope, and the compiler enforces you add a;
after the macro. We use this trick in other macros and all compilers are smart enough to optimize out the jump.Testing:
GUARD_PTR(ctx);
expands to:Here is an example with the macro, and here it is implemented as a traditional if/else. Both result in the same code.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.